是否可以在同一同步组中拥有已加入域和未加入域的服务器?是的。 同步组可以包含具有不同 Active Directory 成员身份的服务器终结点,即使它们未加入域。 虽然从严格意义上讲这种配置可用,但不建议将此作为常规配置,因为在某个服务器上为文件和文件夹定义的访问控制列表 (ACL) 可能无法由同步组中的其他服务器强制实施。 为获得最佳结果,建议在同一个 Active Directory 林中的服务器之间、在不同 Active Directory 林中但已建立信任关系的服务器之间,或在未加入域的服务器之间进行同步。 我们建议你避免混合使用这些配置。
我使用 SMB 或在门户中直接在 Azure 文件共享中创建了一个文件。将文件同步到同步组中的服务器需要多长时间?
与对服务器终结点所做的更改不同,使用 Azure 门户或 SMB 对 Azure 文件共享所做的更改不会立即检测到并复制。 Azure 文件尚没有更改通知或日记,因此无法在文件更改时自动启动同步会话。 在 Windows Server 上,Azure 文件同步使用 Windows USN 日记可在文件更改时自动启动同步会话。
为了检测对 Azure 文件共享所做的更改,Azure 文件同步有一个称为更改检测作业的计划作业。 更改检测作业枚举文件共享中的每个文件,然后将它与该文件的同步版本进行比较。 当更改检测作业确定文件已更改时,Azure 文件同步会启动同步会话。 更改检测作业每 24 小时启动一次。 由于更改检测作业的工作原理是枚举 Azure 文件共享中的每个文件,因此大命名空间用时会长于较小的命名空间。 对于大命名空间,用时可能超过每 24 小时一次,才能确定哪些文件已更改。
若要立即同步 Azure 文件共享中已更改的文件,可使用 Invoke-AzStorageSyncChangeDetection PowerShell cmdlet 手动启动 Azure 文件共享中的更改检测。 此 cmdlet 适用于某些类型的自动化过程在 Azure 文件共享中进行更改或由管理员完成更改(如将文件和目录移动到共享中)的情况。 对于最终用户的更改,建议在 IaaS VM 中安装 Azure 文件同步代理,并让最终用户通过 IaaS VM 访问文件共享。 由此,所有更改都将快速同步到其他代理,而无需使用 Invoke-AzStorageSyncChangeDetection cmdlet。 若要了解详细信息,请参阅 Invoke-AzStorageSyncChangeDetection 文档。
我们正在探讨针对 Azure 文件共享添加类似于针对 Windows Server 上的卷使用的 USN 的更改检测功能。 请在 Azure Community Feedback 上为此功能投票,帮助我们确定将来开发此功能的优先级。
如果在两个服务器上几乎同时对同一文件进行了更改后,会发生什么情况?当 Azure 文件共享中的文件与服务器终结点位置中的文件不匹配时(大小和/或上次修改时间不同),会创建文件冲突。
以下方案可能会导致文件冲突:
在终结点中创建或修改文件(例如服务器 A)。 如果在将服务器 A 上的更改同步到该终结点之前在不同的终结点上修改了同一文件,则会创建冲突文件。创建服务器终结点之前,该文件存在于 Azure 文件共享和服务器终结点位置中。 如果在创建服务器终结点时,服务器和 Azure 文件共享中的文件的大小和/或上次修改时间不同,则会创建冲突文件。由于损坏或达到知识限制,已重新创建同步数据库。 重新创建数据库后,同步将进入名为“核对”的模式。 如果发生核对时,服务器和 Azure 文件共享中的文件的大小和/或上次修改时间不同,则会创建冲突文件。完成到 Azure 文件共享的初始上传后,Azure 文件同步不会覆盖同步组中的任何文件。 相反,它会使用简单的冲突解决策略:同时在两个终结点上保留对文件进行的更改。 最新写入的更改保留原始文件名称。 旧文件(由 LastWriteTime 确定)的终结点名称和冲突号追加到文件名末尾。 对于服务器终结点,终结点名称是服务器名称。 对于云终结点,终结点名称为 Cloud。 名称遵循以下分类:
-[-#].
例如,如果 CentralServer 是较早写入的位置,则 CompanyReport.docx 的第一个冲突将变为 CompanyReport-CentralServer.docx。 第二个冲突将被命名为 CompanyReport-CentralServer-1.docx。 Azure 文件同步支持每文件 100 个冲突文件。 达到最大冲突文件数后,该文件将无法同步,直到冲突文件数小于 100。
我禁用了云分层,为什么服务器终结点位置中存在分层文件?有两个原因可能导致分层文件存在于服务器终结点位置:
向现有同步组添加新的服务器终结点时,如果为初始下载模式选择“首先召回命名空间”选项或“仅召回命名空间”选项,则文件在本地下载下来之前将显示为分层文件。 为避免出现这种情况,请为初始下载模式选择“避免分层文件”选项。 若要手动召回文件,请使用 Invoke-StorageSyncFileRecall cmdlet。
如果已在服务器终结点上启用云分层,然后将其禁用,则文件在被访问之前将保持分层。
为什么分层文件在 Windows 文件资源管理器中未显示缩略图或预览?对于分层文件,不会在服务器终结点显示缩略图和预览。 这是预期行为,因为 Windows 中的缩略图缓存功能有意跳过读取具有脱机属性的文件的操作。 启用云分层后,阅览分层文件将导致它们被下载(召回)。
此行为不是特定于 Azure 文件同步的。Windows 文件资源管理器会为设置了脱机属性的任何文件显示“灰色 X”。 通过 SMB 访问文件时,将看到 X 图标。 有关此行为的详细说明,请参阅为什么无法获取标记为脱机的文件的缩略图?
有关如何管理分层文件的问题,请参阅如何管理分层文件。
为什么分层文件存在于服务器终结点命名空间之外?在 Azure 文件同步代理版本 3 之前,Azure 文件同步阻止将分层文件移到服务器终结点之外但位于服务器终结点所在卷上的其他位置。 复制操作、非分层文件的移动操作以及将分层文件移到其他卷的操作不受影响。 这种行为的原因在于以下隐含假设:文件资源管理器和其他 Windows API 在同一卷上的移动操作是(近乎)即时重命名操作。 这意味着,移动会使文件资源管理器或其他移动方法(如命令行或 PowerShell)看起来没有响应,而 Azure 文件同步会从云中召回数据。 从 Azure 文件同步代理版本 3.0.12.0 开始,Azure 文件同步将允许将分层文件移到服务器终结点之外。 我们通过允许分层文件作为服务器终结点之外的分层文件存在,然后在后台召回该文件以避免前面提到的负面影响。 这意味着在同一卷上的移动是即时的,在移动完成后,我们要完成将文件召回到磁盘的所有工作。
我的服务器上的 Azure 文件同步(同步、云分层等)出现问题。是否应删除并重新创建服务器终结点?
注意:删除服务器终结点不同于重启服务器! 在绝大多数情况下,删除或重新创建服务器终结点不是适合修复同步、云分层或 Azure 文件同步其他方面问题的解决方案。删除服务器终结点是破坏性操作。 当分层文件存在于服务器终结点命名空间之外时,它可能会导致数据丢失。 有关详细信息,请参阅为什么分层文件存在于服务器终结点命名空间之外。 或者,它可能会导致存在于服务器终结点命名空间内的分层文件无法访问。 重新创建服务器终结点后,这些问题并不会得到解决。 即使从未启用过云分层,分层文件也可能存在于服务器终结点命名空间中。 因此,建议不要删除服务器终结点,除非想对特定文件夹停用 Azure 文件同步,或者 Microsoft 工程师明确指示你采取该操作。 有关删除服务器终结点的详细信息,请参阅删除服务器终结点。
是否可将存储同步服务和/或存储帐户移动到不同的资源组、订阅或 Microsoft Entra 租户?是的,可以将存储同步服务和/或存储帐户移动到不同的资源组、订阅或 Microsoft Entra 租户? 移动存储同步服务或存储帐户后,需要向 Microsoft.StorageSync 应用程序授予对存储帐户的访问权限。 执行以下步骤:
登录到 Azure 门户,然后从服务菜单中选择访问控制 (IAM)。
选择“角色分配”选项卡以列出有权访问你的存储帐户的用户和应用程序(服务主体)。
使用“读取器和数据访问”角色验证列表中是否显示“Microsoft.StorageSync”或“混合文件同步服务”(旧应用程序名称)。
如果“Microsoft.StorageSync”或“混合文件同步服务”没有出现在列表中,请执行以下步骤:
选择 添加 。在“角色”字段中,选择“读者和数据访问”。在“选择”字段中键入 Microsoft.StorageSync,然后选择该角色并单击“保存”。注意
创建云终结点时,存储同步服务和存储帐户必须位于相同的 Microsoft Entra 租户中。 创建云终结点后,可以将存储同步服务和存储帐户移到不同的 Microsoft Entra 租户。
Azure 文件同步是否保留目录/文件级 NTFS ACL 以及存储在 Azure 文件中的数据?
从 2020 年 2 月 24 日开始,由 Azure 文件同步分层的新 ACL 和现有 ACL 将持久保留为 NTFS 格式,直接对 Azure 文件共享所做的 ACL 修改将同步到同步组中的所有服务器。 对 Azure 文件共享的 ACL 所做的任何更改都将通过 Azure 文件同步进行同步。将数据复制到 Azure 文件存储时,请确保使用支持必要“保真度”的复制工具,通过 SMB 或 REST 将属性、时间戳和 ACL 复制到 Azure 文件共享中。 使用 Azure 复制工具(如 AzCopy)时,请务必使用最新版本。 检查文件复制工具表获取 Azure 复制工具的概述,以确保可以复制文件的所有重要元数据。
如果在 Azure 文件同步管理的文件共享上启用了 Azure 备份,则可以继续在备份还原工作流中还原文件 ACL。 该操作适用于整个共享或单个文件/目录。
如果使用快照作为文件共享(由 Azure 文件同步管理)的自我托管备份解决方案的一部分,且如果快照是在 2020 年 2 月 24 日之前拍摄的,则 ACL 可能无法正确还原到 NTFS ACL。 如果发生这种情况,请考虑联系 Azure 支持部门。
Azure 文件同步是否会同步目录的 LastWriteTime?为什么目录中的文件更改时,目录上的修改日期时间戳没有更改?否。Azure 文件同步不同步目录的 LastWriteTime。 此外,当目录中的文件发生更改时,Azure 文件存储不会更新目录的修改日期时间戳 (LastWriteTime)。 这是预期的行为。
为什么 AFS 服务器上的防病毒软件召回分层文件?当用户访问分层文件时,某些防病毒软件 (AV) 软件可能会导致意外的文件召回。 如果未将 AV 软件配置为忽略分层文件(具有 RECALL_ON_DATA_ACCESS 属性的文件),则会出现这种情况。下面是发生的具体情况:
用户尝试访问分层文件。AV 软件会阻止读取句柄。然后,AV 应用程序执行自己的读取,以扫描文件查找病毒。此过程可能看起来好像 AV 软件正在召回分层文件,但实际上是由用户的访问尝试触发的。 若要防止此问题,请确保 AV 供应商将其软件配置为忽略使用 RECALL_ON_DATA_ACCESS 属性扫描分层文件。
SSL 检查软件是否可以阻止访问 AFS 服务器?确保 SSL 检查软件(如 Zscaler 或 FortiGate)允许 Azure 文件同步 (AFS) 服务器终结点访问 Azure。 这些 SSL 检查工具可以替代防火墙设置,并有选择地允许流量。 请与网络管理员联系以解决此问题。 使用“testnet”命令确定 AFS 服务器是否遇到此问题。